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Preface  &  Acknowledgements 


Welcome  to  our  Ninth  Annual  Acquisition  Research  Symposium!  This  event  is  the 
highlight  of  the  year  for  the  Acquisition  Research  Program  (ARP)  here  at  the  Naval 
Postgraduate  School  (NPS)  because  it  showcases  the  findings  of  recently  completed 
research  projects — and  that  research  activity  has  been  prolific!  Since  the  ARP’s  founding  in 
2003,  over  800  original  research  reports  have  been  added  to  the  acquisition  body  of 
knowledge.  We  continue  to  add  to  that  library,  located  online  at 

www.acquisitionresearch.net,  at  a  rate  of  roughly  140  reports  per  year.  This  activity  has 
engaged  researchers  at  over  60  universities  and  other  institutions,  greatly  enhancing  the 
diversity  of  thought  brought  to  bear  on  the  business  activities  of  the  DoD. 

We  generate  this  level  of  activity  in  three  ways.  First,  we  solicit  research  topics  from 
academia  and  other  institutions  through  an  annual  Broad  Agency  Announcement, 
sponsored  by  the  USD(AT&L).  Second,  we  issue  an  annual  internal  call  for  proposals  to 
seek  NPS  faculty  research  supporting  the  interests  of  our  program  sponsors.  Finally,  we 
serve  as  a  “broker”  to  market  specific  research  topics  identified  by  our  sponsors  to  NPS 
graduate  students.  This  three-pronged  approach  provides  for  a  rich  and  broad  diversity  of 
scholarly  rigor  mixed  with  a  good  blend  of  practitioner  experience  in  the  field  of  acquisition. 
We  are  grateful  to  those  of  you  who  have  contributed  to  our  research  program  in  the  past 
and  hope  this  symposium  will  spark  even  more  participation. 

We  encourage  you  to  be  active  participants  at  the  symposium.  Indeed,  active 
participation  has  been  the  hallmark  of  previous  symposia.  We  purposely  limit  attendance  to 
350  people  to  encourage  just  that.  In  addition,  this  forum  is  unique  in  its  effort  to  bring 
scholars  and  practitioners  together  around  acquisition  research  that  is  both  relevant  in 
application  and  rigorous  in  method.  Seldom  will  you  get  the  opportunity  to  interact  with  so 
many  top  DoD  acquisition  officials  and  acquisition  researchers.  We  encourage  dialogue  both 
in  the  formal  panel  sessions  and  in  the  many  opportunities  we  make  available  at  meals, 
breaks,  and  the  day-ending  socials.  Many  of  our  researchers  use  these  occasions  to 
establish  new  teaming  arrangements  for  future  research  work.  In  the  words  of  one  senior 
government  official,  “I  would  not  miss  this  symposium  for  the  world  as  it  is  the  best  forum 
I’ve  found  for  catching  up  on  acquisition  issues  and  learning  from  the  great  presenters.” 

We  expect  affordability  to  be  a  major  focus  at  this  year’s  event.  It  is  a  central  tenet  of 
the  DoD’s  Better  Buying  Power  initiatives,  and  budget  projections  indicate  it  will  continue  to 
be  important  as  the  nation  works  its  way  out  of  the  recession.  This  suggests  that  research 
with  a  focus  on  affordability  will  be  of  great  interest  to  the  DoD  leadership  in  the  year  to 
come.  Whether  you’re  a  practitioner  or  scholar,  we  invite  you  to  participate  in  that  research. 

We  gratefully  acknowledge  the  ongoing  support  and  leadership  of  our  sponsors, 
whose  foresight  and  vision  have  assured  the  continuing  success  of  the  ARP: 

•  Office  of  the  Under  Secretary  of  Defense  (Acquisition,  Technology,  &  Logistics) 

•  Director,  Acquisition  Career  Management,  ASN  (RD&A) 

•  Program  Executive  Officer,  SFIIPS 

•  Commander,  Naval  Sea  Systems  Command 

•  Program  Executive  Officer,  Integrated  Warfare  Systems 

•  Army  Contracting  Command,  U.S.  Army  Materiel  Command 

•  Office  of  the  Assistant  Secretary  of  the  Air  Force  (Acquisition) 
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•  Office  of  the  Assistant  Secretary  of  the  Army  (Acquisition,  Logistics,  & 
Technology) 

•  Deputy  Director,  Acquisition  Career  Management,  U.S.  Army 

•  Office  of  Procurement  and  Assistance  Management  Headquarters,  Department 
of  Energy 

•  Director,  Defense  Security  Cooperation  Agency 

•  Deputy  Assistant  Secretary  of  the  Navy,  Research,  Development,  Test  & 
Evaluation 

•  Program  Executive  Officer,  Tactical  Aircraft 

•  Director,  Office  of  Small  Business  Programs,  Department  of  the  Navy 

•  Director,  Office  of  Acquisition  Resources  and  Analysis  (ARA) 

•  Deputy  Assistant  Secretary  of  the  Navy,  Acquisition  &  Procurement 

•  Director  of  Open  Architecture,  DASN  (RDT&E) 

•  Program  Executive  Officer,  Littoral  Combat  Ships 

We  also  thank  the  Naval  Postgraduate  School  Foundation  and  acknowledge  its 
generous  contributions  in  support  of  this  symposium. 

James  B.  Greene  Jr.  Keith  F.  Snider,  PhD 

Rear  Admiral,  U.S.  Navy  (Ret.)  Associate  Professor 
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Acquisition  of  DoD  Complex  Systems 
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Naval  Postgraduate  School 
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Multi-Objective  Optimization  of  System  Capability  Satisficing  in  Defense 
Acquisition 

Brian  Sauser  and  Jose  E.  Ramirez-Marquez 

Stevens  Institute  of  Technology 

Joseph  L.  Yakovac  Jr. — Lt.  Gen.  Yakovac  retired  from  the  United  States  Army  in  2007,  concluding 
30  years  of  military  service.  His  last  assignment  was  as  director  of  the  Army  Acquisition  Corps  and 
military  deputy  to  the  Assistant  Secretary  of  Defense  for  Acquisition,  Logistics,  and  Technology.  In 
those  roles,  Lt.  Gen.  Yakovac  managed  a  dedicated  team  of  military  and  civilian  acquisition  experts  to 
make  sure  America’s  soldiers  received  state-of-the-art  critical  systems  and  support  across  a  full 
spectrum  of  Army  operations.  He  also  provided  critical  military  insight  to  the  Department  of  Defense 
senior  civilian  leadership  on  acquisition  management,  technological  infrastructure  development,  and 
systems  management. 

Previously,  Lt.  Gen.  Yakovac  worked  in  systems  acquisition,  U.S.  Army  Tank-Automotive 
Command  (TACOM),  and  in  systems  management  and  horizontal  technology  integration  for  the 
Office  of  the  Assistant  Secretary  of  the  Army  for  Acquisition,  Logistics,  and  Technology.  He  has  also 
served  as  executive  officer  and  branch  chief  for  the  Bradley  Fighting  Vehicle  and  as  a  brigade 
operations  officer  and  battalion  executive  officer,  U.S.  Army  Europe  and  U.S.  Army  Tank-Automotive 
Command  (TACOM). 

Lt.  Gen.  Yakovac  was  commissioned  in  the  infantry  upon  his  graduation  from  the  U.S.  Military 
Academy  at  West  Point.  He  served  as  a  platoon  leader,  executive  officer,  and  company  commander 
in  mechanized  infantry  units.  He  earned  a  Master  of  Science  in  mechanical  engineering  from  the 
University  of  Colorado  at  Boulder  before  returning  to  West  Point  as  an  assistant  professor. 

Lt.  Gen.  Yakovac  is  a  graduate  of  the  Armor  Officer  Advanced  Course,  the  Army  Command  and 
General  Staff  College,  the  Defense  Systems  Management  College,  and  the  Industrial  College  of  the 
Armed  Forces.  He  has  earned  the  Expert  Infantry  Badge,  the  Ranger  Tab,  the  Parachutist  Badge, 
and  for  his  service  has  received  the  Distinguished  Service  Medal,  the  Legion  of  Merit  three  times  and 
the  Army  Meritorious  Service  Medal  seven  times. 
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System  Definition-Enabled  Acquisition  (SDEA) — A  Concept 
for  Defining  Requirements  for  Applying  Model-Based 
Systems  Engineering  (MBSE)  to  the  Acquisition  of  DoD 

Complex  Systems 

Paul  Montgomery — After  retiring  in  1990  from  a  20-year  career  in  the  Navy,  Dr.  Montgomery  served 
as  a  senior  systems  engineer  with  Raytheon  and  Northrop  Grumman  corporations  and  developed 
communications,  surveillance,  and  sensor  systems  for  commercial,  military  (USN,  USA,  USAF),  and 
intelligence  communities  (NSA,  NRO).  He  earned  his  doctorate  in  systems  engineering  from  George 
Washington  University  (DSc  ’07),  performing  research  related  to  cognitive/adaptive  sensors,  MSEE 
(1987)  from  Naval  Postgraduate  School,  and  BSEE  (1978)  from  Auburn  University.  The  International 
Council  on  System  Engineering  (INCOSE)  certifies  him  as  an  expert  systems  engineering 
professional  (ESEP).  Dr.  Montgomery  is  an  SE  Department-embedded  faculty  member  providing 
onsite  research  and  instruction  support  to  NAVAIR  (Patuxent  River,  MD),  NAVSEA  (Dahlgren,  VA; 
Carderock,  MD),  and  NPS  SE  students  in  the  Nation  Capital  Region,  [prmontgo@nps.edu] 

Ron  Carlson — Carlson  served  26  years  in  naval  aviation  as  a  pilot,  seven  years  of  which  were  at 
NAVAIR  where  he  led  NAVAIR  systems  engineers  through  several  years  of  systems  engineering 
revitalization  to  the  NPS  SE  Department.  He  is  currently  in  the  systems  engineering  doctoral  program 
at  Stevens  Institute  of  Technology  and  has  earned  master’s  degrees  in  strategic  studies  and  national 
policy  from  the  Naval  War  College  and  business  administration-aviation  from  Embry  Riddle 
Aeronautical  University,  and  a  Bachelor  of  Science  in  nuclear  engineering  from  the  University  of 
Michigan.  Ron  Carlson  is  an  SE  Department-embedded  faculty  member  providing  onsite  research 
and  instruction  support  to  NAVAIR  (Patuxent  River,  MD),  NAVSEA  (Dahlgren,  VA;  Carderock,  MD), 
and  NPS  SE  students  in  the  Nation  Capital  Region,  [rrcarlso@nps.edu] 

John  Quartuccio — Quartuccio  has  more  than  27  years  of  civilian  service  within  the  Naval  Air 
Systems  Command  and  the  Naval  Air  Warfare  Center.  He  graduated  from  The  Pennsylvania  State 
University  with  a  Bachelor  of  Science  in  mechanical  engineering  in  1985,  and  graduated  from  Lehigh 
University  with  a  Master  of  Science  in  applied  mechanics  in  1997.  He  is  currently  an  NPS  systems 
engineering  PhD  student.  Quartuccio  is  the  director  of  the  Systems  Engineering  Development  and 
Implementation  Center  (SEDIC)  within  Air  Platform  Engineering  (AIR-4.1 .1)  of  the  Systems 
Engineering  Department.  He  is  also  a  member  of  the  AIR-1 .0  staff  as  APEO(E)  for  AIR-1 .0  Programs. 
[john.quartuccio@navy.mil] 

Abstract 

The  complexity  of  designing  and  acquiring  weapons  systems  continues  to  increase  due  to 
highly  integrated  system  architectures,  rapid  technology  evolution,  and  emergence  of  highly 
diverse  set  of  missions.  The  imperatives  of  system-of-systems  integration  and  interoperability 
further  complicate  the  system  acquisition  process.  These  challenges  continue  to  frustrate 
completing  the  acquisition  of  systems  within  time  and  budget  goals.  The  acquisition  process 
is  currently  aligned  to  a  DoD  5000/WSARA  model  which  tends  to  be  oversight-driven,  but  this 
process  needs  to  be  underpinned  with  a  robust  and  dynamic  systems  engineering  enterprise 
that  includes  repeatable  and  quantifiable  design-driven  processes  and  metrics  in  order  to 
cope  with  complexity  and  a  less  experienced  workforce. 

This  paper  discusses  a  concept  for  an  engineering  system  that  is  tightly  coupled  to  the 
acquisition  process  to  (1)  reduce  acquisition  time,  (2)  reduce  risks  in  achieving  system 
integration  and  interoperability  objectives,  (3)  controls  total  ownership  costs,  (4)  informs 
industry  in  the  development  of  a  system  definition-enabled  acquisition  set  of  tools,  processes, 
or  products  that  are  emerging  in  the  model-based  systems  engineering  community,  and  (5) 
supports  the  emergence  of  a  younger  engineering  workforce  as  the  seasoned  veterans  retire. 
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Background  and  Problem  Definition 
Setting  the  Stage 

One  of  the  authors  recently  attended  a  vendor  presentation  of  their  model-based 
systems  engineering  (MBSE)  tool.  While  the  tool  is  useful  for  straightforward  systems,  the 
author  challenged  the  vendor  to  improve  their  product  to  better  align  to  the  needs  of  DoD 
acquisition  of  complex  systems  and  asked  when  such  product  improvements  could  be 
expected.  The  answer  was  reasoned  and  insightful:  “When  DoD  gives  us  the  requirements.” 
This  was  not  a  glib  answer  and,  in  fact,  despite  the  ever-increasing  number  of  MBSE  tools 
and  products  on  the  market  from  several  vendors,  the  DoD  has  yet  to  provide  a  set  of 
requirements  for  an  integrated  tool  set.  This  paper  discusses  a  way  to  get  started  on 
defining  such  a  set  of  requirements.  We  discuss  some  foundational  problems  and  needs 
associated  with  DoD  complex  systems  acquisition  and  a  potential  path  forward  to  develop 
an  integrated  set  of  tools  (an  engineering  system).  We  call  this  concept  system  definition- 
enabled  acquisition  (SDEA). 

Complex  Systems  Acquisition 

The  current  DoD  acquisition  process  (see  Figure  1 ),  as  specified  in  DoD  5000,  has 
gone  through  many  adjustments  and  has  a  long  heritage  of  acquisition  experience  based 
upon  the  acquisition  of  stand-alone  systems  (DoD,  2008).  Today’s  system  acquisitions  are 
more  co-dependent  on  the  development  of  other  complex  systems  in  a  “systems-of- 
systems”  (SoS)  environment.  This  requires  a  higher  level  of  coupling  between  system 
engineering  and  the  acquisition  process  to  support  SoS,  as  well  as  the  need  for  higher 
levels  of  lead  system  integrator  (LSI)  support. 


Concept  Development  & 

Validation 

Design  Development  & 

Validation 

Produce  &Qualify 

Deploy  &  Improve 


Figure  1.  DoD  5000  Acquisition  Process 

Note.  This  figure  was  derived  from  DoD,  2008. 

Figure  1 ,  however,  does  not  actually  depict  a  process  nor  does  it  indicate  any 
integrated  engineering  process.  It  shows  a  schedule  framework  that  drives  the  development 
of  the  system  from  needs  on  the  left  to  a  product  on  the  right.  In  the  middle  are  large-scale 
activity  goals  that  each  culminate  in  major  or  minor  milestones.  These  milestones  provide  an 
opportunity  for  major  elements  in  DoD  or  systems  command  (e.g.,  NAVAIR,  NAVSEA, 
SPAWAR,  etc.)  acquisition  leadership  organizations  to  observe  the  status  and  progress  of 
the  system  design  and  overall  acquisition  performance.  In  reality,  the  engineering  process  is 
not  depicted  on  this  diagram  at  all.  Each  organization  is  allowed  to  define  and  describe  the 


ru.i  m---ii,.riE:  virY]iU| 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CEEANGE 


-11  - 


process  it  will  follow  to  design  a  system,  qualify  the  system,  produce  the  system,  and 
ultimately  deploy  the  system.  This  paper  examines  the  question,  how  can  we  describe  a 
companion  engineering  system  that  supports  the  acquisition  system  that  embraces  the 
higher  levels  of  SoS  system  complexity,  integration  challenges,  interoperability,  and  LSI 
support? 

System  complexity  and  system-of-systems  interoperability  continue  to  frustrate  this 
acquisition  timeline  and  increase  program  costs.  The  rapid  pace  of  technology  and  the 
overall  system  complexity  that  is  being  faced  and  encountered  today  continues  to  rise  at  a 
level  with  which  many  engineers  and  engineering  organizations  struggle  to  cope. 
Additionally,  many  systems  are  the  integration  of  several  systems  that  are  being  acquired 
and  developed  independently  and  for  their  own  purposes.  The  systems  are  integrated  to 
produce  a  new  emergent  behavior  to  satisfy  new  and  emergent  warfare  doctrine.  This  SoS 
method  rarely  affords  the  opportunity  to  affect  the  design  of  these  co-dependent  systems. 
The  functionality,  interfaces,  operational  objectives,  and  intended  system  environments  all 
provide  a  challenge  to  ensure  that  the  system-of-systems  can  be  integrated  successfully 
while  producing  new  emergent  behaviors  that  are  predictable  and  satisfy  the  user  needs. 
Couple  all  of  this  complexity  and  SoS  realities  to  the  existing  system  engineering  methods, 
practices,  principles,  organization  old  behaviors,  and  workforce  skills,  and  what  emerges  is  a 
distinct  need  for  a  system  that  supports  a  quantifiable  and  repeatable  engineering 
methodology  that  also  supports  a  younger  and  less  experienced  workforce.  Figure  2  depicts 
the  demographics  of  DoD  SE-certified  engineers  and  clearly  shows  a  dearth  of  experienced 
engineers  “behind”  the  retiring  and  very  experienced  “baby  boomer”  engineers. 


Figure  2.  Credentialed  DoD  Systems  Engineers  (SPRDE-SE/PSE)  Age  Demographic 

Q1  2011 

(Welby,  2010) 

The  above  challenges  are  relatively  well  known  in  both  the  industrial  and  DoD 
communities  and  continue  in  the  discourse  in  both.  The  International  Council  of  Systems 
Engineering  (INCOSE),  for  example,  has  set  a  long-range  goal  of  aiding  the  emerging 
workforce  with  greater  SE  tools  (INCOSE,  2007)  and  processes  and  methods  (INCOSE, 
2008).  Both  communities  are  actively  developing  hardware,  software,  and  systems  tools  to 
cope  with  the  development  of  complex  systems.  In  recent  years,  the  systems  engineering 
(SE)  community  has  been  developing  model-based  systems  engineering  (MBSE)  tools  and 
methods  to  help  discipline  the  design  and  development  of  systems  (e.g.,  Vitech,  201 1 ;  IBM, 
2012).  The  good  news  is  that  many  tools  are  available  to  assist  the  engineer  to  develop 
solutions  across  a  wide  variety  of  system  needs.  The  bad  news  is  that  there  is  a  very  large 
selection  of  tools,  they  are  not  well  integrated,  and  they  are  often  highly  tailored  for  narrow 
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applications.  The  result  is  a  seemingly  endless  landscape  of  un-integrated  tools,  methods, 
views,  and  techniques  for  system  development  (see  Figure  3).  The  challenge  is  to  provide 
the  DoD  engineering  community  an  “engineering  system”  based  upon  many  of  these 
existing  tools,  coupled  with  tailored  tools  which  will  provide  a  more  integrated,  repeatable, 
quantifiable  process  rather  than  continuing  with  the  disjointed  tool  sets  and  ad-hoc 
processes. 


Figure  3.  Model-Based  Systems  Engineering  (MBSE)  Tools  and  Practices  Are 

Diverse  and  Sometimes  Inconsistent 

Note.  This  figure  was  derived  from  Estefan,  2008. 

Problem  Definition 

The  background  in  the  previous  sections  leads  to  a  discussion  of  problems  with 
current  acquisitions  that  are  diverse,  not  necessarily  new,  and  can  be  divided,  as  shown  in 
Figure  4  and  discussed  as  follows. 
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Figure  4.  Problem  Dimensions  of  Acquisitions 
Acquisition  Timeliness 

Acquisitions  often  exceed  schedule  objectives.  The  acquisition  structure  depicted  in 
Figure  1  is,  in  effect,  a  document-driven  and  technical  review-driven  process;  therefore,  it 
tends  to  be  non-adaptive  to  changing  requirements  and  mission  needs.  This  can  result  in  a 
slower  process  that  delivers  systems  that  fall  short  or  do  not  meet  user  needs  despite  the 
pressure  on  all  acquisitions  to  deliver  on  schedule  and  on  budget.  The  systems  that  are 
developed  by  the  acquisition  process  need  to  have  risk-managed  processes  that  are  not  just 
qualitative  (the  dominant  method  used  today)  but  also  quantitative  where  the  risks  can  be 
measured  with  accepted  and  agreed-upon  metrics  that  can  be  tightly  coupled  and  integrated 
into  an  engineering  system.  There  is  an  emphasis  on  prototypes  as  a  key  feature  of  early 
acquisition  activities  in  DoD  5000  (2008).  Without  a  tightly  coupled  engineering  system,  this 
can  lead  to  prototypes  demonstrating  technologies  alone  that  are  too  loosely  coupled  to 
engineering  goals,  objectives,  and  requirements.  Finally  the  acquisition  process  and  the 
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supporting  engineering  system  often  do  not  have  longevity  in  a  quantifiable  way  such  would 
support  such  things  as  pre-planned  programmed  improvements  (P3I)  are  qualified  in  the 
future. 


Acquisition  Process 

The  acquisition  process  is  not  design-driven.  The  DoD  5000  acquisition  process  is 
oversight-driven  and  document-driven.  The  success  of  such  a  process  will  depend  upon  the 
judgments  of  overseers  detecting  errors  and  the  quality  of  the  documentation.  Currently,  the 
quality  of  the  acquisition  process  is  correlated  on  those  judgments  rather  than  a  direct  result 
of  quantifiable  metrics  that  emerge  from  a  system  engineering  system  where  the  status  and 
quality  of  the  design  can  be  assessed  repeatedly,  with  less  dependence  on  the  experience 
and  judgment  of  the  overseer.  Because  each  system  command  and  each  system 
engineering  organization  in  each  acquisition  organization  can  develop  their  own  engineering 
processes  and  methods  and  practices,  the  ability  to  coordinate  between  agencies  in  a 
quantifiable  and  repeatable  fashion  is  fraught  with  incompatibilities  and  risks.  This  leads  to 
duplicative  programs  or  low  levels  of  interoperability.  Cost  optimization  is  very  difficult  to 
achieve  because  system  performance  is  hard  to  quantifiably  measure  as  the  system  is 
being  developed  and  assessments  and  trade-offs  are  being  made.  Finally,  there  is  limited 
modeling  of  the  system  to  vet  lessons-learned  which  would  enhance  one’s  ability  to  make 
supportability  improvements  or  forge  an  improvement  strategy. 

System  Complexity 

System  complexity  exceeds  engineering  system  capabilities.  Simple  systems  and 
complex  systems  proceed  to  the  acquisition  process  with  essentially  the  same  attentions.  It 
is  up  to  the  program’s  engineering  processes,  methods,  and  systems  to  cope  with  the  ever- 
increasing  number  of  complex  systems.  Current  engineering  processes  reflect  the 
experiences  of  relatively  simple  systems  but  must  be  adapted  to  high  levels  of  complexity 
and  interoperability.  Given  certain  failures  of  large  systems  in  recent  years  in  which  the 
government  assigned  LSI  responsibilities  to  a  contractor,  there  are  initiatives  to  assign  the 
LSI  responsibilities  back  to  the  government.  This  will  require  a  level  of  engineering 
processes  closely  integrated  with  program  management  processes.  A  key  need  in  this  area 
is  the  ability  to  assess  SoS  performance  and  the  emergence  system  behaviors  in  a 
quantifiable  manner.  The  operational  test  community  and  the  design  community  need  to  be 
working  toward  the  same  goals  when  assembling  an  SoS  which  is  a  key  lead  system 
integrator  responsibility. 

Integration  and  Interoperability 

Systems  fail  at  integration  or  are  not  meeting  interoperability  objectives.  The  key 
risks  associated  with  integration  of  systems,  especially  system-of-systems,  is  the  existence 
of  functional  gaps  and  overlaps  among  the  systems.  Give  the  number  and  complexity  of  the 
functions;  we  cannot  simply  depend  on  system  engineering  technical  reviews  to  discover 
these  functional  inconsistencies.  Generally,  these  functions  and  the  interfaces  should  be  as 
simple  as  possible,  modular,  and  associated  with  clear  performance  metrics  for  ultimate 
qualification.  Incompatibilities  or  inconsistencies  among  interfaces  and  functions  are  a 
leading  cause  of  integration  failures  for  systems  during  their  acquisition  cycle  (Bahill  & 
Henderson,  2005).  These  discoveries,  especially  near  the  end  of  the  acquisition  cycle,  are 
extraordinarily  expensive  and  time-consuming.  System-of-systems  integration  also  demands 
the  interoperability  among  these  systems  as  well  as  the  interoperability  outside  of  the 
system  for  other  systems  that  are  codependent.  It  is  imperative  that  the  behavior  of  the 
acquired  system  and  the  behavior  of  the  associated  external  systems  be  clearly  understood, 
measurable,  predictable,  and  risk-managed  throughout  the  acquisition  cycle. 
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Total  Ownership  Costs 

Total  ownership  costs  (TOC)  are  difficult  to  predict  and  control.  The  acquisition  cost 
incurred  during  the  development  cycle  is  only  a  fraction  of  the  total  ownership  cost  of  any 
system.  In  fact,  the  development  cost  is  often  the  minority  cost  component  of  the  TOC  of  the 
system  throughout  its  lifetime.  The  engineering  methods  and  engineering  system  that  are 
used  during  the  acquisition  of  the  system  needs  to  have  measurable  and  quantifiable  factors 
that  accurately  predict  total  ownership  cost  of  the  system.  These  metrics  and  vectors  also 
need  to  be  able  to  aid  the  support  community  in  controlling  the  TOC  in  the  long  run.  If  the 
system  is  discovered  to  have  unusual  failure  modes,  inconsistent  emergent  behaviors, 
incompatible  interfaces,  and  so  forth,  the  system  will  need  improvements  or  modifications. 
This  can  have  major  TOC  impact.  These  discoveries  are  often  unwanted  surprises  and/or 
negative  emergent  behaviors  that  should  be  avoided  during  the  engineering  and  acquisition 
phase.  The  engineering  system  needs  to  have  very  detailed  predictable  and  repeatable 
behavior  modeling  of  both  the  acquired  system  and  external  systems  in  order  to  try  to 
anticipate  these  negative  TOC  effects.  This  is  a  nontrivial  demand  on  the  acquisition 
engineering  system.  It  requires  a  high  level  of  probability  prediction,  failure  analysis, 
operational  modeling  and  analysis,  interface  performance  prediction,  and  other  forward- 
looking  engineering  activities  that  are  often  not  present  in  the  current  engineering  system. 
The  current  system  is  driven  on  the  need  to  deploy  a  system  at  the  end  of  the  acquisition 
cycle  and  all  focus  is  on  that  point.  The  engineering  system,  therefore,  should  be  focused  on 
the  TOC  and  total  lifecycle  engineering  goals  and  system  performance  and  not  just  the 
acquisition  cycle. 

Workforce  Support 

The  veteran  engineers  are  retiring  at  a  dramatic  pace  and  are  not  being  replaced 
with  engineers  with  commensurate  experience.  The  design  process  and  the  attendant 
system  that  supports  the  development  of  the  system  during  the  acquisition  cycle  needs  to 
provide  high  levels  of  repeatability  and  quantifiability  that  is  less  dependent  on  engineering 
judgment  and  more  dependent  on  metrics  that  provide  a  highly  refined  engineering  solution. 
In  the  past,  the  development  of  tools  to  provide  such  repeatable  and  quantifiable  design 
metrics  was  often  far  more  expensive  than  assigning  experienced  engineers  to  apply  their 
judgment  to  the  solution.  Given  that  many  seasoned  veteran  engineers  are  retiring  and  that 
the  state  of  the  art  of  computer-based  tools  has  been  highly  enriched  in  recent  years,  there 
is  a  need  to  provide  system  design-driven  metrics  and  artifacts  to  a  younger  engineering 
community.  This  community  is  often  far  more  adept  at  using  computer-based  tools  and 
computer  systems  than  the  retiring  engineers.  Additionally,  the  complexity  of  current 
systems  makes  it  virtually  impossible  for  the  rising  workforce  to  cope  without  a  high  level  of 
engineering  support  system.  In  fact,  even  current  systems  require  too  much  “heroism”  of  a 
few  extraordinarily  experienced  engineers  to  ensure  system  development  success.  A 
system  that  provides  project-to-project  consistency  and  repeatability  would  be  of  the  most 
value  since  the  common  matrix  organization  of  many  engineering  organizations  often 
requires  an  engineer  to  provide  part-time  focus  on  any  particular  project,  and  it  would  be 
beneficial  if  the  focus  method  was  the  same  for  each  project  experience  using  the  same 
metrics,  processes,  methods,  and  principles. 

Research  Questions 

Our  fundamental  thesis  is  that  the  DoD  needs  to  describe,  in  a  systematic  manner, 
what  is  needed  in  an  engineering  system  that  drives  the  acquisition  as  much  by  system- 
definition  details  and  modeling,  as  it  does  by  documentation  and  oversight;  thus  our  term, 
system  definition-enabled  acquisition  (SDEA).  As  we  embark  on  determining  how  SDEA 
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could  be  applied  to  DoD  acquisition,  we  need  to  investigate  several  questions  that  lead  to 
the  solutions  of  the  problems  discussed  in  the  previous  section.  These  include  the  following: 

•  What  is  an  SDEA  concept  of  operation? 

•  What  are  the  SDEA  requirements? 

•  What  is  an  SDEA  architecture? 

•  What  are  the  SDEA  components,  elements,  tools,  etc. 

•  What  tools  are  available  today? 

•  Where  do  these  tools  fall  short  in  satisfying  the  needs  of  the  acquisition 
community? 

•  How  might  the  SDEA  affect  organizational  roles  and  responsibilities? 

•  What  are  SDEA  solicitation  strategy  key  elements? 

These  research  questions  result  from  the  perception  that  a  new  approach  is  needed 
to  view  the  acquisition  engine  and  associated  engineering  system  from  a  system 
perspective.  Instead  of  a  standalone  engineering  process  in  which  the  primary  objective  is  to 
produce  the  necessary  engineering  documentation  and  perform  well  at  the  associated 
acquisition  reviews  that  are  vetted  by  highly  seasoned  and  experienced  engineers,  how  can 
the  system  be  defined  and  described  such  that  it  could  actually  be  designed,  viewed  by  all, 
and  acquired  as  a  system  in  and  of  itself?  While  there  are  many  policies  in  place  at  the 
various  systems  commands,  there  is  still  a  great  deal  of  freedom  on  how  to  execute  these 
policies  from  an  engineering  perspective.  What  if  there  was  a  system  that  produced 
repeatable  and  quantifiable  system  engineering  methods  and  practices  and  metrics  such 
that — whether  you  were  at  one  systems  command  or  another,  or  developing  a  system  that 
needed  to  interoperate  with  another — an  engineer  could  ensure  that  the  risk  associated  with 
the  development  of  the  system  could  be  developed  in  a  low-risk  fashion? 

There  are  many  MBSE  tools  being  advertised  from  several  vendors,  and  the 
research  questions  focus  on  the  fact  that  these  tools  are  individually  inadequate  to  solve  the 
total  engineering  problem  addressed  in  this  paper.  There  may  be  a  way  to  integrate  these 
tools  with  other  associated  capabilities  to  create  a  system  that  provides  all  the  features  we 
have  outlined  so  far.  The  research  questions  focus  on  what  the  capabilities  are  of  these 
tools,  how  they  map  against  the  needs  and  requirements  of  the  acquisition  community,  and 
finally,  what  would  be  needed  in  addition  to  integrate  these  tools.  Finally,  if  an  SDEA 
engineering  system  were  available,  how  could  the  organizations  that  are  in  place  today 
utilize  the  system,  or  in  what  ways  must  they  make  change  or  adapt  in  order  to  provide  the 
higher  level  of  performance  which  has  been  enabled  by  SDEA? 

System  Definition-Enabled  Acquisition  (SDEA)  System  Concept 

Top-Level  Concept 

The  top-level  SDEA  concept  is  shown  in  Figure  5.  The  SDEA  system  comprises  the 
essential  engineering  activities  today.  The  SDEA  concept,  however,  is  not  to  view  the 
engineering  system  as  a  collection  of  individual  activities  but  rather  a  system  itself  that 
provides  repeatable  and  quantifiable  performance.  The  SDEA  system  is  synergistic  with  the 
program  definition,  system  definition,  supportability  definition,  and  system  production 
activities.  Note  that  all  of  these  activities  are  responsive  to  the  originating  stakeholders, 
program  resources  and  management,  TOC,  and  future  improvements  to  the  system.  The 
SDEA  system  is  envisioned  to  retain  all  the  necessary  information  that  defines  and  models 
the  system  even  after  all  the  activities  are  complete  during  development.  This  ensures  that 
there  will  be  a  set  of  engineering  artifacts  and  metrics  that  allow  for  a  low  risk  and  highly 
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success-oriented  opportunity  for  system  improvement  in  the  future.  In  the  diagram,  program 
definition  is  supported  by  the  SDEA  system  and  the  SDEA  system  is  dependent  upon 
program  definition  for  the  delineation  and  definition  of  a  program  of  record  (i.e.,  at  the 
Pentagon).  Program  definition  leads  to  system  definition  and  the  handoff  contract 
(documents)  associated  with  system  capabilities  and  top-level  performance  goals. 
Additionally,  program  definition  leads  to  documentation  and  agreements  that  set  in  motion 
long-term  supportability  strategies  and  activities  such  as  logistics,  training  and  manpower, 
and  long-term  supply  chain  strategies.  The  SDEA  system  supports  both  system  definition  in 
a  very  repeatable,  quantifiable  manner  as  well  as  provides  clear  detail  and  system  reliability 
and  supportability  metrics  to  the  definition  of  the  support  system  associated  with  the 
acquisition.  System  production  is  dependent  upon  system  definition  and  the  objectives  of 
the  support  community  as  well  as  the  metrics  that  come  from  the  supporting  SDEA  system 
in  order  to  proceed  to  production  of  the  system  in  preparation  for  deployment.  Once  again, 
the  SDEA  system  as  depicted  in  this  diagram  is  not  just  the  encapsulation  of  disjoint 
engineering  activities  or  their  associated  methods  and  tools,  but  rather  an  integrated  system 
that  can  be  employed  and  deployed  in  any  acquisition  activity. 


Figure  5.  SDEA  Provides  Central  Engineering  System  Support  to  Acquisition 

Current  Acquisition  Engineering  Approaches 

Let  us  examine  a  view  of  today’s  acquisition  process  to  explore  how  SDEA  might  be 
employed.  Figure  6  depicts  current  engineering  practices  as  largely  document-driven  and 
expert-centric.  On  the  left,  needs  are  originated  by  operational  users  which  are  articulated  in 
operational  language  such  as  a  concept  of  operation  (CONOP),  requirements  that  are 
articulated  in  user  terms,  and  an  architecture  that  is  top  level  in  its  nature  and  depicts  the 
constraints,  legacy  systems,  and  the  external  systems  that  are  key  elements  to  provide  the 
capabilities  desired.  These  sets  of  documents  frame  the  boundaries  upon  which  a  program- 
of-record  (PoR)  is  ultimately  built,  justified,  and  defended.  The  processes  that  are  depicted 
on  the  left  side  of  that  diagram  (often  executed  at  the  sponsor’s  level)  are  essentially 
repeated  at  the  acquisition  agency  (systems  commands).  These  documents  and  artifacts 
that  represent  either  the  user  needs  or  the  system  requirements  can  produce  several 
solutions  that  need  to  be  vetted  to  produce  a  single  path  forward.  Skilled  and  experienced 
engineers  assimilate  the  wide  variety  of  information  produced  by  the  documentation  and 
synthesize  a  preferred  alternative.  The  result  is  a  dedicated  set  of  documents,  potentially 
with  a  database  of  requirements,  that  is  forwarded  on  to  the  development  engineering 
community,  also  made  up  of  seasoned  veterans  who  examine  the  wide  variety  of 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CHANGE 


- 18- 


engineering  issues  such  as  interfaces,  architecture,  operational  analysis,  risk  management, 
modeling  and  simulation,  and  so  forth.  This  engineering  community  supports  the  larger 
acquisition  process  by  delivering  opinion  and  assessments  into  the  major  design  reviews, 
trade  studies,  and  so  forth.  This  process,  therefore,  proceeds  from  design  documentation  to 
system  document  analysis  to  an  oversight-oriented  acquisition  process. 


f 


System  Design  Documentation 

* 

System  Documentation  Analysis 


1 


CtHTCp 

0 


Oversight-oriented  Acquisition  (W&ARA) 


Interfaces 

Operations 

Architecture 


Qualification 


Management 


Model  &  Sim 


SETRs 

Trade  Studies 

TOC  Analysis 

LSl/ScS 

Quaff  cation 

Basel  tie  Mgmt 

PH 


Figure  6.  Current  Top-Level  Engineering  Workflow  During  System  Acquisition 
SDEA  System  Approach 

How  does  the  SDEA  concept  differ  from  today's  engineering  workflow?  As  shown  in 
Figure  7,  the  left  side  of  the  SDEA  workflow  diagram  where  user  needs  are  articulated, 
requirements  are  generated  and  architectures  are  developed  essentially  the  same  as 
before.  The  major  difference  is  that  these  definitions  become  part  of  a  system 
baseline/model  that  is  entered,  analyzed,  and  vetted  in  a  tool-enabled  environment.  The 
SDEA  system  definition  environment  can  semi-automatically  generate  system  alternatives 
and  rank  them  against  a  variety  of  value  perspectives.  The  key  at  this  juncture  is  that 
although  system  experts  will  still  be  needed  to  apply  judgment  at  this  juncture  in  system 
design,  an  SDEA  system  can  provide  algorithms  based  upon  the  data  that  are  in  the  system 
definition  model  that  can  answer  questions  in  a  quantifiable  manner,  which  then  enables  a 
higher  level  of  judgment  to  be  applied  to  a  higher  level  of  complex  systems.  At  this  juncture, 
therefore,  we  are  not  examining  documentation  to  develop  a  viable  system  solution;  we  are 
performing  system  analysis  in  a  way  that  multiple  engineers  can  ask  the  same  question  of 
the  system  definition  and  get  the  same  answer  repeatedly,  which  reduces  decision  risks 
along  the  way.  When  an  alternative  is  produced,  there  is  a  high  likelihood  that  the  system 
design  solution  that  has  been  derived  from  a  system  definition  model  will  satisfy  the  needs 
of  the  user,  and  the  user  will  have  some  level  of  assurance  that  it  will  meet  integration  and 
interoperability  goals  when  deployed. 

This  system  solution  is  passed  to  the  right  side  of  the  diagram,  which  provides  not 
only  documentation  to  the  teams  that  must  assess  the  various  dimensions  of  system 
performance,  but  also,  and  more  importantly,  provides  detailed  data  that  enables  analysis  of 
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system  interfaces,  architectures,  functionality,  behaviors,  interoperability  predictions, 
quantifiable  risk  measurements,  and  so  forth.  These  are  the  aspects  of  the  system  that  must 
pass  scrutiny  as  various  design  reviews  in  the  acquisition  process.  By  keeping  the  SDEA 
system  as  a  system  definition  oriented  system  and  supported  in  a  software-enabled  system, 
we  can  aid  the  engineering  community  in  coping  with  highly  complex  and  highly 
interoperable  systems  in  a  way  that  assures  success  in  a  dynamic  warfare  environment. 

System  Definition  and  Models 
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Figure  7.  SDEA  Engineering  Workflow  During  System  Acquisition 
SDEA  Application  Examples 

System  Interface  Design  and  Analysis 

Figure  8  (left)  shows  an  example  of  the  current  engineering  practices  when 
examining  interfaces.  When  performing  interface  design  and  analysis  activities  for  system 
development,  experienced  engineers  will  often  use  an  interface  control  document  (ICD) 
which  details  the  system  interfaces  and  balances  against  other  architectural  documentations 
such  as  the  DoD  Architecture  Framework  (DoDAF)  architectural  views  (drawings).  This 
process  can  often  be  extremely  tedious  and  error-prone.  Only  the  most  experienced  and 
seasoned  veterans  of  interface  analysis  and  design  have  any  likelihood  of  success  given  a 
system  of  any  complexity.  Most  are  still  likely  not  to  discover  errors,  gaps,  incompleteness, 
and  so  forth. 
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Figure  8.  Current  and  SDEA  Interface  Design  Analysis 

In  the  SDEA  approach  shown  (Figure  8,  right),  interface  analysis  can  be  semi- 
automated  to  assist  the  engineer.  The  architectural  views  are  not  simply  drawings  but  are 
software  models  that  are  carefully  built,  connected,  and  defined  in  several  different  methods. 
The  parameterized  interface  descriptions  can  be  compared  and  contrasted  in  the  SDEA 
system  algorithms  to  produce  a  level  of  measure  that  indicates  the  quality  of  the  design  for 
the  interfaces.  This  frees  the  engineer  to  not  be  mired  in  the  minutia  of  interface 
bookkeeping  but,  rather,  to  apply  judgment  to  whether  or  not  the  analysis  of  the  interface  is 
sufficient  to  support  system  operations. 

System  Operational  Analysis 

Another  SDEA  comparison  is  shown  in  Figure  9.  When  performing  operational 
analysis,  the  engineering  team  is  often  faced  with  reconciling  an  initial  capabilities  document 
(ICD),  a  concept  of  operation  (CONOP),  and  the  attendant  architectural  views  that  may  or 
may  not  have  been  created  by  the  same  creators  of  the  documents  themselves.  Once 
again,  only  a  seasoned  veteran  with  many  years  of  experience  in  reading,  analyzing,  and 
reconciling  operational  documents  can  have  a  high  likelihood  of  analyzing  whether  or  not 
the  associated  architectural  results  will  support  the  operational  needs  of  the  user. 
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Figure  9.  Current  and  SDEA  Operational  Analysis 

The  SDEA  example  in  Figure  9  (right)  is  a  model-driven  approach  enabling  that 
functionality,  physicality,  and  behaviors  are  all  described  with  great  detail  in  a  system  model. 
This  provides  a  high  level  of  repeatability,  such  that  the  SDEA  system  itself  can  provide 
some  level  of  semi-automated  metrics  of  how  the  system  will  ultimately  operate.  This  frees 
the  engineering  team  from  reconciling  documentation  and  enables  assessing  total  system 
performance  against  the  originating  user  needs  for  operations. 

SDEA  Integrated  Acquisition  Support 

The  SDEA  system  will  provide  a  data-driven  system  definition  and  model-driven 
systems  engineering  approach  that  supports  both  the  system  engineering  and  design 
communities  as  well  as  the  acquisition  community  with  their  associated  processes  (see 
Figure  10). 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CHANGE 


-22- 


Figure  10.  SDEA  Provides  Quantifiable  Analysis  in  Support  of  Multiple  Perspectives 
SDEA  System  Development  and  Transition 
SDEA  Development 

Relating  back  to  the  opening  vignette,  has  the  DoD  provided  the  MBSE  vendor 
community  a  DoD  set  of  requirements  that  would  start  to  create  SDEA?  Not  yet,  but  Dr. 
Stephen  Welby,  Assistant  Secretary  of  Defense  for  System  Engineering,  casts  many  MBSE 
long-range  goals  for  2020  that  start  a  conversation  about  many  of  the  SDEA  concepts 
(Welby,  2010). 

The  development  of  the  SDEA  system  requires  the  transformation  of  engineering 
practices  and  methods,  but  not  necessarily  principles.  Visionary  principles  essentially  remain 
the  same,  but  there  are  many  factors  that  need  to  be  transitioned  in  order  for  the  SDEA 
system  to  be  a  vibrant  part  of  the  acquisition  cycle.  Figure  1 1  depicts  the  challenge  areas  for 
SDEA  transition  and  each  is  briefly  discussed  in  the  following  paragraphs. 


Figure  11.  Challenges  to  SDEA  Transition 
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Organizational  Processes 

The  two  dominant  organizations  of  program  definition  (Pentagon)  and  the  acquisition 
community  need  to  be  mutually  supported  by  the  SDEA  system  and  need  to  have  a 
common,  error-free  handoff  between  their  roles  in  the  acquisition  cycle.  Both  teams  need  to 
be  trained  on  how  this  handoff  occurs,  and  how  the  SDEA  system  supports  the  development 
of  the  program  and  the  subsequent  development  of  system  top-level  design. 

Analysis  of  Alternatives 

Using  the  SDEA  system,  engineering  teams  need  to  understand  how  to  use  semi- 
automated  quantification  of  system  analysis  that  emerges  from  such  a  system  in  order  to 
make  higher-level  judgments  and  selections  of  higher-level  system  complexities  and 
system-of-systems.  This  workflow  is  not  necessarily  in  place  today. 

Workforce  Development 

SDEA  will  provide  more  refined  analysis  tools  to  exploit  that  system  data  for 
engineers  to  use  to  develop  such  analysis  as  interfaces,  architectures,  and  so  forth.  The 
workforce  will  need  to  be  trained  in  how  to  employ  those  analysis  tools  and  how  to  interpret 
the  data  such  that  a  repeatable  level  of  performance  is  achieved. 

Management  Integration 

The  SDEA  system  needs  to  seamlessly  support  all  of  the  associated  processes  and 
tools  that  are  in  place  in  the  program  management  of  the  system  acquisition  process  with 
special  recognition  on  cost  and  schedule  and  stakeholder  support. 

Modeling  and  Simulation 

The  SDEA  system  offers  new  opportunities  for  the  modeling  and  simulation 
community  to  support  acquisition.  In  many  cases,  the  modeling  and  simulation  community  is 
required  to  develop  the  model  of  the  system  based  on  documentation  and  then  perform 
simulation  to  assess  some  portion  of  system  performance.  Under  the  SDEA  concept,  the 
model  is  essentially  developed  in  the  SDEA  system,  allowing  the  modeling  and  simulation 
community  to  focus  more  on  simulation  parameters,  performance,  and  analysis  against  a 
vetted  system  model. 

The  SDEA  system  will  also  produce  system  models  that  can  also  execute  to  produce 
a  measure  of  whether  or  not  the  selected  architecture  and  system  solution  is  viable  and  will 
meet  essential  performance  needs.  This  can  obviate  the  need  to  expend  time  and  money  on 
modeling  and  simulation  elsewhere.  It  can  help  perform  concept  validation,  initial  top-level 
performance  assessment,  and  essential  interface  analysis  that  can  save  a  significant 
amount  of  time  and  cost  during  the  early  design  phases  (thus  saving  acquisition  time). 

DoD  Acquisition  Process 

The  SDEA  system  will  not  replace  the  acquisition  system  but  rather  seamlessly 
integrate  and  support  all  of  the  milestone  delineated  phases  of  the  acquisition,  the  design 
reviews,  the  gate  reviews,  as  well  as  the  other  oversight  and  documentation  of  the 
acquisition  system. 

SDEA  Transition 

The  SDEA  system  need  not  be  developed  in  a  vacuum.  Most  of  the  engineering 
communities  in  the  major  Navy  Systems  Commands  are  currently  examining  MBSE 
techniques,  as  well  as  examining  how  to  provide  more  system  definition  through  the  use  of 
tools  in  the  engineering  community.  Our  initial  plan  is  to  focus  on  the  naval  aviation 
enterprise  to  develop  the  needs,  goals,  objectives,  assumptions,  constraints,  and  initial 
requirements  for  SDEA.  Our  strategy  is  as  follows: 
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•  establish  advocacy  and  develop  an  SDEA  champion  within  the  naval  aviation 
systems  command; 

•  select  an  exemplar  program  to  examine  their  baseline  system  processes; 

•  build  a  system  description  of  those  processes; 

•  compare  and  contrast  an  SDEA  system  approach  to  those  baseline  processes; 

•  demonstrate  and  analyze  the  value  of  the  SDEA  system  against  that  comparison; 

•  begin  a  campaign  of  consensus  building;  and 

•  develop  a  solicitation  strategy  for  the  development  of  an  SDEA  system. 

Summary 

The  following  salient  issues  drive  the  need  for  a  transformation  of  a  system 
definition-enabled  acquisition  (SDEA)  engineering  system.  The  DoD  needs  to  turn  these 
issues  into  needs  and  requirements,  and  energize  the  MBSE  vendor  community  to  develop 
an  integrated  solution  for  an  SDEA  system  that  supports  the  design  and  acquisition  of 
complex  systems  and  SoS. 

•  Systems  continue  to  grow  more  complex  and  are  often  over  stripping  region 
nearing  community's  ability  to  manage  risk  and  predict  performance. 

•  System-of-systems  acquisition  and  the  government  assuming  the  role  of  the  lead 
system  integrator  will  become  the  norm. 

•  The  workforce  experience  level  will  be  contracting  over  the  next  decade  as  the 
baby  boomers  retire  and  the  younger  engineers  grow  into  that  role. 

•  Disciplined,  repeatable,  and  quantifiable  engineering  tools  and  methods  need  to 
be  enhanced. 

•  SDEA  system  technology  is  already  partially  available,  however,  not  yet  fully 
integrated 

•  Organizational  requirements  for  the  SDEA  system  need  to  be  defined  as  a  total 
system  rather  than  purchasing  individual  tools. 
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ystem  DefinitioruEnabled  Acquisition 


•  Problem  Definition 

•  Where  at  we  at,  today? 

•  What  is  SDEA? 

*  How  can  we  best  apply  SDEA? 

*  Why  not  apply  SDEA  today? 

*  How  do  we  get  there? 
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SDEA  at  NAVAIR 

PROBLEM  DEFINITION 


•  Systems  Engineering  (SE) 

-  The  DoD  SE  community  and  process  is  current 
unable  to  fully  support  acquisition  in 
development  of  complex  systems 

*  Support  for  SEs 


—  System  Engineers  need  a  innovative  system  to 
help  them 

Definition 

-  SEs  need  define  that  system 
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Where  are  w@  (®oD)  Going'? 

■  DoD  and  Sqg/LSI  (Gansler) 


SoS  acquisition  and  engineering  is  the 
norm  in  DoD 

SoS  design,  integration  and 
qualification  (l&Q)  is  highly  complex 
DoD  engineering  workforce  not  well 
aligned  to  LSI  responsibilities 

Government  oversight  of  LSI  has  been  com 
contractual  ambiguities 

Delineation  of  “inherently  governmental  functions”  for  LSI 
needs  more  clarity 

Private  LSIs  have  inherent  conflicts  of  interests  without 
specific  controls 

SoS  integration  requires  a  strong,  centralized  LSI 


What  is  the  problem? 


•  Acquisition  timeliness 

•  System  complexity 

•  TOC 

•  l&l  risks 

•  Workforce  support 

•  Acquisition  process 


*  Document-driven 

*  Oversight-oriented 

*  Acquisition  too  long 

*  Poor  TOC  control 

*  Poor  quantification  (what-ifs  /  trades...) 

*  Lack  of  repeatability  (too  “greybeard”  dependent) 

*  No  longevity  of  baselines  for  P3I 

*  Inability  to  cope  w/complexity,  SoS,  LSI 

*  Integration  not  coupled  early  enough 

*  Interoperability  not  well  quantified  or  predictable 

*  l&Q  risks  too  high 


Stakeholders,  Program  Resources, 


SDEA  Context 
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Research  Questions 


•  What  are  SDEA  requirements? 

•  What  are  SDEA  components,  elements,  tools, 
etc. 

•  What  are  available  today? 

•  Where  do  they  fall  short? 

•  How  might  SDEA  affect  org  roles  and 

responsibilities? 

-  JCIDS,  WSARA,  ... 

-  Pentagon-vice-SysComs 

•  What  are  SDEA  solicitation  strategy  key 
elements? 


SDEA 

Where  at  we  at,  today? 
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As-ls 


Motor  Period  Register  Address 

This  register  is  used  to  set  the  period  of  clock  pulses  to  the  motor  circuitry.  This  period  defines  the 
frequency  of  the  stepper  motor  clock. 

Operation:  Write  8-bit  value  to  this  addressed  register  to  set  the  divisor  for  the  internal  4KHz  clock; 
thus,  defining  the  resulting  period  of  the  stepper  motor  clock.  Ex.  4000/register  =  period  of 
stepper  clock. 

I/O  Address:  0x292 
Active  State:  NA 

Data  Bus  Mapping:  DB7-DB0  (DB7  =>  MSB) 

Access  Mode:  Write 

Motor  Command  Register  Address 

This  register  is  used  to  setup  motion  control  for  a  particular  motor  circuitry. 

Register  Bit  Descriptions: 

Motor  Stop  Bit:  Set  this  bit  to  stop  the  motor  at  any  time.  Setting  this  bit  resets  the  internal  start 
bit,  but  does  not  reset  the  “position”  or  "period”  register. 

Motor  Direction  Bit:  Set  this  bit  to  define  the  direction  of  motor  rotation.  Set  high  for  CW;  low  for 
CCW. 

Motor  Start  Bit:  Toggle  this  bit  from  low  to  higl 
trigger  bit.  In  order  to  start  the  motor  after  a  pi 
be  toggle  from  low  to  high  again. 

Motor  and  Sensor  Selection  Bits  (mtrsell  .mtrs 

encode  the  motor  and  corresponding  tracking 
The  following  encoding  table  maps  these  four 


Interface 

Control 

)ocument 


DoDAF  “views’ 


Sel2  Sell  Sen2  Senl 


Carousel  Motor 


Carousel  Motor 


Carousel  Motor 


Carousel  Motor 


1  Carousel  Motor 


Interface  Control  Document 


ZoZo  Engineering  400  Spear 


Not  D( 

Read 

Read  * 

Not  Dt 
Fluidic 

Fluidic 

Fluidic 

NotDt 

Cartric 

Barcoi 

Read 

Carou 

j^eTf  OPERATIONAL  NODES 
Not  D<  ARE  ASSOCIATED 

-  WITH  SYSTEMS  NODE! 

AND  SYSTEMS 


OPERATIONAL 
NEEDLINES  MAP  TO 
SYSTEMS  INTERFACES 


Not  D 


SYSTEMS  INTERFACE  DESCRIPTION 
(SV-1) 


VALUE ADDED: STATEMENT  OF 
SYSTEMS  NODES,  SYSTEMS,  4 
INTERFACES;  SUMMARIZED  SYSTEM 
INFORMATION  EXCHANGES 


Integrated 
Dictionary  (A\A2)  is 
not  shown  but 
relates  to  all  other 
products 
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As-ls 


ICD 


Conop 


r7 


DoDAF  “views” 


r7 


SDEA 


Requirements 

Functions 

Interfaces 

Physical  components 

Behaviors 

Timing 

Verification 

Use  Cases 

Resources 

Risks 

ssue 


r - 

— 

tr 

i  ” 

r  ~ 

ip  i 

/# 

p  i  / 

Tr  t 

If 

fez- 

I h 

(L; 

-  rrr 

o . 

fit 

at 

¥F 

— 

0 

it: 

H 

Figure  1.  Sample  Function  Flow  Block  Diagram  (FFBD) 
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DoDAF  “views” 


SDEA 


Requirements 

Functions 

Interfaces 


Physical  components 

Behaviors 

Timing 


SDEA 


System  Engineering  & 
Design 

Interfaces 

Operations 

Architecture 

Qualification 

Risk 

Management 


Model  &  Sim 


nables  Acquisition 


System 

Definition 

Baseline 


System  Engineering  & 
Acquisition 

SETRs 

Trade  Studies 

TOC  Analysis 

LSI/SoS 

Qualification 

Baseline  Mgmt 

P3I 


SDEA 

How  can  we  best  apply  SDEA? 
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Strong  impact 

-  “  Complex’'  systems 

-  Mission  systems 

-  High  levels  of  integration 

-  System  of  Systems 

-  Weapons  system  integration 

-  Emerging  acquisitions  (UCAS,  UAS,  JSF,  etc.) 

Supporting  impact 

-  “Complicated”  systems 

-  Airframe 

-  Propulsion 

-  P3I  -  parts 
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SDEA 

Why  not  apply  SDEA  today? 
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L 


Tool  and  HSI  Consistency  in  S 


System  Design 
Validation,  Analysis, 
and  Determination 
Events 


Team  training  /  Application  non-specific 


Interfaces 

Operations 

Architecture 

Qualification 

Risk 

Management 

Model  &  Sim 


if!  SETRs 


'« . 


Trade  Studies 

TOC  Analysis 

LSI/SoS 

Qualification 

Baseline  Mgmt 

P3I 
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Analy 


System  Design 
Validation,  Analysis, 
and  Determination 
Events 


Quantifiable,  semi-automated 
design  analysis  not  well 
established 


it  Qf  alternatives 


Interfaces 

Operations 

Architecture 

Qualification 

Risk 

Management 

Model  &  Sim 


if!  SETRs 


'« . 


Trade  Studies 

TOC  Analysis 

LSI/SoS 

Qualification 

Baseline  Mgmt 

P3I 
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System  Design 
Validation,  Analysis, 
and  Determination 
Events 


Interfaces 


Operations 

Architecture 

Qualification 

Risk 

Management 

Model  &  Sim 


Baseline  Mgmt 


SETRs 

Trade  Studies 


TOC  Analysis 


LSI/SoS 


Qualification 


Team  training  on  SDEA  analytical  methods 


29 


Management  integration 


Not  well  integrated  into  PM/SE  management  methods 
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System  Design 
Validation,  Analysis, 
and  Determination 
Events 


Interfaces 

Operations 

Architecture 

Qualification 

Risk 

Management 

Model  &  Sim 


if!  SETRs 


'« . 


Trade  Studies 

TOC  Analysis 

LSI/SoS 

Qualification 

Baseline  Mgmt 

P3I 


Now  well  integrated  into  system/ops  M&S  methods/tools 
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xecutable  rflQdels 


Interfaces 


Operations 


Architecture 


Qualification 


Risk 


Management 


Model  &  Sim 


if!  SETRs 


'« . 


Trade  Studies 

TOC  Analysis 

LSI/SoS 

Qualification 

Baseline  Mgmt 

P3I 


Non-executable  models 
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“Conop” 


System  Design 
Validation,  Analysis, 
and  Determination 
Events 


Baseline  Mgmt 


SETRs 

Trade  Studies 

TOC  Analysis 

LSI/SoS 

Qualification 


Not  completely  tailored  to 
DoD  5000  /  WSARA 
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SDEA 

How  do  we  get  there? 
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•  Select  exemplar  program 

•  Build  system  description 

•  Demonstrate  application  of  SDEA 

•  Demonstrate/analyze  value 

•  Consensus  check 

Solicitation(s) 
Prototypes 
Research 
Studies 
Trials 


Goal: 

-  Develop  a  SysCom  SDEA(MBSE/I): 

•  Needs 

•  Goals  and  objectives 

•  Assumptions  and  constraints 
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SDEA 

SUMMARY 
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SDEA  (MBSE/I) 


•  Systems  grow  more  complex 

•  Systems  of  systems  (SoS)  and  LSI  will  be 
the  norm 

•  Experience  base  is  shrinking 

•  Disciplined,  repeatable,  and 
quantifiable  SE  practices  needed 

•  SDEA  technology  is  partially  available 

•  Navy  SysCom  requirements  for  SDEA 
need  to  be  defined  for  SDEA  methods, 
practices,  and  tool  acquisition 
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QUESTIONS  /  DISCUSSIONS 
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BACKUPS 
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Validation 


System  risks 
Operational  risks 

Risk 

Integration  risks 
Interoperability  risks 
Qualification  risks 


Operations 


Mission  analysis 
Activity  definition 
Interoperability  analysis 
Operational  integration 
Conop  definition 

User  needs  analysis 
Problem  definition 


Functionality 


Functions 

Functional 

Interfaces 

Logical 

Functional  integration 
Functional  interactions 

Interoperability 
Emergent 


System  behaviors 


Physical 


Integration  (functional)  analysis 
Components/Elements/Units 
Physical 

Interfaces 

Compatibility  analysis 
Integration  (physical)  analysis 
Interoperability  analysis 
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